Technical Field
This disclosure relates generally to configuration of software components used in a distributed computing environment, where such components are used to produce logs for purposes of compliance analysis, problem determination, and forensics, among others.
Background of the Related Art
Businesses often have to provide information to show compliance with different government regulations. These regulations include, for example, the Sarbanes-Oxley (SOX) Act, the Health Insurance Portability and Accountability Act (HIPAA), and the like. Often times, compliance with these and other regulations may be shown using information contained in audit logs maintained by information technology (IT) organizations. For compliance reasons, these audit logs often are maintained for years. Audit logs are useful for checking the enforcement and effectiveness of information technology controls, accountability, and vulnerability, and/or risk analysis. An information technology organization also may use auditing of security related critical activities to aid in forensic investigations, such as security incidents that may occur. When a security incident occurs, an audit log enables an analysis of the history of activities that occurred prior to the security incident occurring. These activities include, who did what, when, where, and how. With the analysis of an audit log, appropriate corrective actions may be taken. Audit logs are typically made available in relational databases to allow easy querying of the information by reporting programs or software to generate operational and trend reports.
While compliance may be seen to ensure the ability to ensure that a security policy is enforced, compliance may also be applied to other types of policy, such as service level agreements (e.g. using timestamps on audit logs to ensure that an overall Service Level Agreement (SLA) is satisfied), legislative compliance (e.g., on control or release of privacy-related information), or even policy management itself (e.g., who changed a policy, when and how, and was it in compliance with the policy for compliance-policy-management).
Further, compliance with a particular policy, or a detailed forensics examination of actions within a system, may require more than just “audit” logs. It may also require access to error and trace logs, typically used within the scope of a problem determination examination.
When determining a system's compliance with a desired policy, typically logs (such as audit logs) are searched and used as the basis for validating that a policy is successfully implemented and/or a user is bound by that policy. While such approaches generally work well for their intended purpose, one difficulty with this approach is that as more and more components become involved in the overall information flow, there are many more sources of audit log records. Typically, each of these sources corresponds to a single compliance component, and there may be multiple individual components in the workflow, each individually configurable with respect to an audit policy. In such case, the evaluation of audit policy to ensure compliance with that policy depends on the configuration of multiple components, where each component must be individually configured to produce the audit records required for compliance demonstration.
Further, the evaluation of compliance with an overall audit policy may require more or less detail than is required for an individual component's audit evaluation. As an example, one compliance analysis may require that an action against a component triggered by a “root level” user be traced an entire way through a system. This may require tracking events that normally would be generated as part of trace logging utilities and thus configured independently of an audit log facility. Prior approaches do not provide the capability to address this type of requirement.